home *** CD-ROM | disk | FTP | other *** search
/ Developer CD Series 1997 January: Mac OS SDK / Dev.CD Jan 97 SDK2.toast / Development Kits (Disc 2) / OpenDoc Development Framework / ODF-Interest Archive / June 96 / Re Linking & ODF Draw.3 < prev    next >
Encoding:
Internet Message Format  |  1996-12-03  |  3.2 KB  |  [TEXT/ttxt]
  1. Subject:     Re: Linking & ODF Draw
  2. Sent:        6/4/96 9:49 AM
  3. Received:    6/4/96 2:01 PM
  4. From:        Scott, scottdfl@sprynet.com
  5. Reply-To:    ODF Interest, ODF-Interest@CILabs.ORG
  6. To:          OpenDoc Development Framework Discussion List, ODF-Interest@CILabs.
  7.  
  8. > Date:          3 Jun 1996 14:46:45 -0700
  9. > Reply-to:      ODF-Interest@CILabs.ORG
  10. > From:          "Mary Boetcher" <mary_boetcher@quickmail.apple.com>
  11. > To:            OpenDoc Development Framework Discussion List <ODF-Interest@CILabs.ORG>
  12. > Subject:       Re: Linking & ODF Draw
  13.  
  14. >         Reply to:   RE>>Linking & ODF Draw
  15. > 
  16. > >>It appears that the indices are assigned when 
  17. > >>the part is internalized from storage, via "PostInternalizeShape", 
  18. > >>ditto for the selection. So, if I create a new document, draw some 
  19. > >>shapes, save the doc, and reopen it, the shapes will be numbered 
  20. > >>1..n. Then I paste some more shapes, now my doc's shape list is 
  21. > >>numbered 1..n, 1..m. Now I select some shapes (including some that I 
  22. > >>just pasted in). Let's say I have 8 shapes altogether, numbered 1..5, 
  23. > >>1..3, and I select the first, third and last shape. When I copy, the 
  24. > >>selection is externalized with the shape indices of 1, 3 & 3.
  25. > Actually the selection is externalized with the shape indices of 1, 2 & 3, because
  26. > the index is reset in CDrawContent::ExternalizeShapeList. However, I see a 
  27. > potential problem when this selection is
  28. > internalized. If the part's existing 
  29. > shapes are numbered 1..n, then CDrawPart::FindShapeWithIndex may 
  30. > return the wrong shape. I will investigate this further.
  31.  
  32. > Hope this helps,
  33. > 
  34. > Mary Boetcher
  35. > ODF Person
  36. > 
  37.  
  38. Mary,
  39.  
  40. I am so sorry, but I am still confused. I understand the basic 
  41. concept of linking, and the OpenDoc creating of link objects for the 
  42. source and dest. links. What I don't understand is the purpose of 
  43. writing the indices. In your original reply, you seem to indicate 
  44. that the indices are only used in a single link context, but they 
  45. seem to stored in the document as well. Also, what about multiple 
  46. links? Since the part's content is searched by index, you must have 
  47. unique indices for all the shapes in the part's content, buth they 
  48. seem to be assign for both the part & the link contents.
  49.  
  50. You admitted there may be a bug in ODF Draw in this area. In any 
  51. event, I can not tell (obviously from my previous oversight you 
  52. pointed out) what the indices are for. Could you please explain or 
  53. point me to some documentation that would elaborate on exactly what I 
  54. am supposed to do to support linking? As I mentioned in my first 
  55. post, I am writing graphical shapes somewhat like Draw, but in the 
  56. part content, they are not stored sequentially, but they are stored 
  57. sequentially in the selection content. So, I can number them in the 
  58. selection or link content (and even the part content I suppose), but 
  59. I need to know how and when to do this. Especially if ODF Draw has 
  60. some bugs in this matter, I obviously don't want to propigate those 
  61. bugs to my part. Could you please give me a suitable scheme for my 
  62. part?
  63.  
  64. Thanks very much for your help. I am sorry to be so dense, but Henri 
  65. did say to ask where the documentation was lacking <g>.
  66.  
  67. Scott Daniels
  68. e-mail: scottdfl@sprynet.com
  69. "Life appears the way you choose to see it"
  70.